Electronic devices such as, for example, mobile phones and personal digital assistants (PDA's), often contain firmware and application software that are either provided by the manufacturers of the electronic devices, by telecommunication carriers, or by third parties. If firmware or firmware components are to be changed in such electronic devices, it is often very tricky to update the firmware or firmware components.
It is often difficult to determine what is wrong with an electronic device when a problem is encountered. Quite often, a customer care representative for a system operator does not have answers to a customer's problem and is not able to fix it. Determination of problems with a customer's mobile device is a big problem for system operators. Answering customer care calls is quite expensive. Especially so, if at the end of such a call, the customer care representative is unable to determine what is wrong with the electronic device.
Different electronic devices have different sets of resources, different sets of parameters, etc. Managing mobile devices in a heterogeneous communication network is a huge problem. Figuring out what parameters need to be set is also a problem.
Device profile evolution (DPE) techniques do not exist yet, although feeble attempts may have been made in the form of extending existing UAProf techniques to include some support for device parameter adjustments based on content to be delivered to a device. Recently, the Open Mobile Alliance (OMA), that supports the UAProf techniques, has begun exploring the need to support device profile evolution (DPE), and some use-cases have been discussed to determine its need.
However, since an electronic device can undergo a firmware update (or software update) and acquire new capabilities, a mechanism is needed that addresses the determination of new capabilities and the detection of new capabilities, from an external server as well as by a user of the electronic device. The OMA UAProf technique of sending user agent information to a wireless application protocol (WAP) server or WAP gateway does not seem to address that. UAProf and the proposed OMA DPE work address sending user agent properties to address temporary needs of an application or service being (or about to be) consumed. However, they do not support determination or communication of information on features added to the electronic device that have a long term impact such as, for example, that due to firmware updates, etc. DPE has been proposed (and is not yet a reality) to support device-specific rendering, and device-specific delivery of content, based on parameters related to some device capability. In addition DPE seems to support a narrow set of use-cases related to (mostly temporary) changes to electronic device settings in order to make it possible to consume a service.
UAProf and the proposed DPE do not provide any help regarding the support for an optional feature for an OMA enabler implementation. For example, if an electronic device supports firmware update capability, then it must be possible to determine whether the device is capable of that feature/enabler implementation. However, this determination is not possible with UAProf based technique and even the proposed work of DPE, which is likely to be delivered as a specification in 2007 or beyond.
The features (such as OMA enablers) supported by an electronic device need to be supported, and UAProf based technique currently does not support that. In addition, if however, an optional sub-feature such as, for example, client-initiated firmware update (e.g., for a feature called “firmware update”) is not supported by a device, this needs to be determined too (ideally). However, neither UAProf based technique nor the proposed DPE support such determination.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with the present invention as set forth in the remainder of the present application with reference to the drawings.